home *** CD-ROM | disk | FTP | other *** search
/ Night Owl 6 / Night Owl's Shareware - PDSI-006 - Night Owl Corp (1990).iso / 033a / prevnt31.zip / WHAT'S.NEW < prev   
Text File  |  1990-10-13  |  9KB  |  200 lines

  1. PREvent 3.10
  2. PCBoard Rotary Event Manager
  3. Release 10-13-90
  4. by Jeff Woods
  5.  
  6. Users new to the 3.x series, please skip to the 3.0 notes, as the bug
  7. fixes herein do not concern you unless you are naturally curious.
  8.  
  9. _________________________________________________________________________
  10.  
  11. Welcome back to a release-a-day, but this SHOULD be the last bug fix to
  12. the month specific events.   While installing this on the Telix BBS I
  13. discovered what I thought was a minor bug.   In all my home
  14. run-throughs, testing every possible setup I could think of, everything
  15. worked, so I sat down to write the docs.   As I was writing, it occured
  16. to me that DA/31 should cause it to run on the last day of the month, no
  17. matter HOW many days the month had in it.   So I went back and added
  18. that one line, carefully thinking out the logic in that section.    The
  19. testing sequence I used was about an hour long, and my logic couldn't be
  20. that far off (so I thought) so it was not retested.   BAD mistake,
  21. folks.    That threw one DILLY of a bug in the program, for which I
  22. apologize.   When looking at the printout at work, it seemed that the
  23. bug would ONLY affect those who had a DA/01 to be run earlier in the
  24. file than the current event.   So I let it ride until I got home.   Now
  25. 4 hours later, I finally have what turned into a monster of a problem
  26. licked, and yes, completely run through the testing series again, and
  27. not one jot has changed in this posting.   That little line change
  28. (added an extra 'or' to and 'if' statement) caused it to ALWAYS use the
  29. last event found that was valid, to in effect not stop looking after the
  30. first valid event found.
  31.  
  32. In the process, I also straightened up the error-trapping on the time of
  33. the events, locking out 23:58 to 00:02 as PCBoard does.
  34.  
  35. I also discovered an EXTREMELY obscure bug, so thorough was the testing
  36. this time.   It seems that PREvent would, when happening on a D02/29 in
  37. a non-leap year, tell you you had an invalid day of the month on that
  38. line.   Now if it is February, it will accept a 29 for the day of the
  39. month, and simply skip it if it is not a leap year.   Why ANYONE would
  40. want to run the events ONLY on a leap year is beyond me, but now that
  41. definitely works.
  42.  
  43. I honestly think I got the thing working right this time, but then, I
  44. said that last time, didn't I?   <grin>   Well, what do you expect for
  45. free?  <another grin>   Let's hope this time is the charm, and we don't
  46. need a third time.
  47.  
  48.  
  49.  
  50. PREvent 3.0
  51. PCBoard Rotary Event Manager
  52. Release 10-12-90
  53. by Jeff Woods
  54.  
  55. _________________________________________________________________________
  56.  
  57. Re-wrote completely, streamlining a few routines, and modularizing the
  58. code a bit.   I know you don't care about that *too* much, but I was
  59. busting my hump to get the last version working correctly, and it wasn't
  60. too pretty at all.   Now it's much more readable, although still pretty
  61. much uncommented.... ;-)
  62.  
  63. Fixed a few minor bugs in error trapping invalid entries in the data
  64. file.   Added error trapping to the field for the TIME of an event.
  65.  
  66. Fixed a moderate bug in computing events that were the first to occur on
  67. a Sunday (i.e. first one in PREVENT.LST with a 6 in the data line).
  68. This only hit you if this was the ONLY event to run on Sunday, and the
  69. last event was the ONLY one to run on Saturday.
  70.  
  71. Added support for day of the MONTH specific events.   Below is the
  72. excerpt from the new docs about how this works.
  73.  
  74. -----------------------------------------------------------------------
  75.  
  76. The new optional format for the first line for an event is new to
  77. version 3.0.   It allows events to run only on specific days of the
  78. MONTH, or in a given month only.   Substituting this line for a valid
  79. days of the month line will allow this, if the following format for
  80. month-specific events is followed:
  81.  
  82. Dmm/dd
  83.  
  84. Where mm is the month, and dd is the day.   Both MM and DD MUST have two
  85. digits, so use D01/01 for January first, etc.   You may substitute the
  86. letter "A" for mm, and it will run on the dd'th day of EVERY month.  An
  87. example line for that might be for events that compress and clean up
  88. caller logs on the first of each month:
  89.  
  90. DA/01
  91.  
  92. The slash is significant, and must separate mm and dd.
  93.  
  94. Here are a few examples of events that will run on given days of the
  95. MONTH:
  96.  
  97. D05/15  (will run ONLY on may 15th)
  98. DA/10   (will run on the tenth of EVERY month)
  99. DA/31   (will run on the LAST day of every month with 31 days)
  100. D02/29  (will run once every four years, on leap year)
  101.  
  102. Yes, Prevent is smart enough to make a few assumptions now.   It knows
  103. how many days are in each month and adjusts for leap years as well.   It
  104. also will adjust automatically to operate flawlessly, determining which
  105. event is next (there was a minor bug in the day of the week specific
  106. routines in 2.5 - fixed).
  107.  
  108. -----------------------------------------------------------------------
  109.  
  110. Unlike the 2.x series, in which I joined Omen in the release of the day
  111. club, I took my time here, carefully testing out each possible
  112. configuration, even the obscure ones.   I am fairly confident that since
  113. this one was not rushed out the door that it is sans pests.
  114.  
  115. ------------------------------------------------------------------------
  116.  
  117. Lastly, some hints on what to do with this new-found power.
  118.  
  119. Set up an event to run:
  120.  
  121. DA/01
  122. 00:03,n,4,y,30
  123.  
  124. Have it compress your caller logs (these go down by roughly 85%) and
  125. then delete the buggers.   If you are using Sam Smith's CAL14S20 or
  126. some other such, the event can also reset the .SAV files to keep a
  127. bulletin of JUST the month's activity, all hands off.
  128.  
  129. Set up spaced events.   Let's say you want to reset Tradewars every
  130. three months.  Four events spaced out such will relieve you of having to
  131. do that.
  132.  
  133. Set up an event every six months to run Norton Calibrate or Gibson's
  134. Spinrite at the deepest scan.   It may take a while, but you'll never
  135. have to wonder if it's time to do it again.   It is always a GOOD idea
  136. to do a low level once every six months unless you are using SCSI or
  137. ESDI formats.
  138.  
  139. Set up an event once a month (if you have a tape backup) to do a FULL
  140. backup of the system while you sleep.    Then have bi-weekly events do
  141. incrementals on your most important files, like USERS, etc.   It
  142. relieves you of having to back up.
  143.  
  144. Message packing is nice, and so is disk optimizing, but it can be hard
  145. on your disk.  If you have the space, set up a full Norton's Speed Disk
  146. or some such once a month, or maybe twice.  You can do events TWICE a
  147. month simply by having:
  148.  
  149. DA/01   and
  150. DA/15
  151.  
  152. Then you can use a de-fragger that is much easier on the drive every
  153. other day (via a 0246 event) such as Fasttrax or Vopt.   Prevent will
  154. thus help you prolong the life of your hard disk.
  155.  
  156. ------------------------------------------------------------------------
  157.  
  158. Well, enough rambling.   I thought I'd give you some insight as to why I
  159. added the new monthlies, and as to how I now have my system configured
  160. with the new features.   I'm sure you'll think of others.
  161.  
  162. And yes, PREvent 3.0 is STILL public domain software.    I retain the
  163. copyright to the work in that only I can say I wrote it, distribute
  164. source code (no, I won't), or sell it (no, I don't - it's FREE).   But
  165. anyone is welcome to use it, abuse it, give it to others, or simply
  166. throw it away.   I wrote it because I needed it, and it'd be pretty
  167. blasted selfish not to let you use it as well.   If you DO like the
  168. program and feel you simply MUST do something for me, tell your users
  169. about my board and it's largest and most well kept catalog of Adlib and
  170. Sound Blaster Files in North America.   We are the only board that rates
  171. our Blaster files, and listens to (and cleans up pops and breaks from
  172. poor recordings) each and every file we obtain.   So, enjoy, and let me
  173. know how you like the new found freedom.
  174.  
  175. Jeff Woods                   The Musical Chair
  176. October 12th, 1990           HST Dual Standard
  177. Toronto, ON                  Adlib/SoundBlaster Files
  178. 1:17 am EST                  416-438-3009
  179.  
  180. -------------------------------------------------------------------------
  181.  
  182.  
  183. Prevent 2.5 released 09/09/90
  184.  
  185. Thanks to Dave Pointer of Grayson, GA, for pointing out (no pun intended) a
  186. logic error in the way error levels were returned in 2.0 through 2.3.
  187.  
  188. Prevent has always returned the errorlevel based on the NEXT event to
  189. run, but with the addition of day specific events, the errorlevel may no
  190. longer be valid if an event is skipped because it is not a specific day.
  191.  
  192. Thus, the errorlevel now returned is based on the CURRENT event running,
  193. and will require some changes to your EVENT.SYS.   I reccommend reading
  194. the PREVENT.DOC file that deals with the section on using the
  195. errorlevels as it makes things all clear.
  196.  
  197. The docs were completely re-written as with this change, new users would
  198. have to read the old docs backwards, and it could get very confusing.
  199.  
  200.